home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / tsql / doc / tsql.mail / 000120_csj@iesd.auc.dk _Thu May 13 16:16:48 1993.msg < prev    next >
Internet Message Format  |  1996-01-31  |  4KB
  1. Received: from iesd.auc.dk by optima.CS.Arizona.EDU (5.65c/15) via SMTP
  2.     id AA08651; Thu, 13 May 1993 07:16:48 MST
  3. Received: from yellow.iesd.auc.dk by iesd.auc.dk with SMTP id AA03200
  4.   (5.65c8/IDA-1.5/MD for <tsql@cs.arizona.edu>); Thu, 13 May 1993 16:16:48 +0200
  5. Date: Thu, 13 May 1993 16:16:48 +0200
  6. From: "Christian S. Jensen" <csj@iesd.auc.dk>
  7. Message-Id: <199305131416.AA03200@iesd.auc.dk>
  8. To: tsql@cs.arizona.edu
  9. Subject: Re:  Benchmark Query Taxonomy
  10.  
  11. Dear Fabio,
  12.  
  13. I thank you for your consistent interest in the benchmark. Below, I
  14. attempt to provide an adequate answer to your problem. As you, I hope
  15. this reply may also benefit other contributors.
  16.  
  17. The query to be categorized is
  18.  
  19.      Find the date of birth of *ED*.
  20.  
  21. I will categorize the query according to the taxonomy as summarized in
  22. Figure 6 of the benchmark document. When that is done, classification
  23. according to the coarser Figure 7 is trivial.
  24.  
  25. Output: I assume that the expected answer to the query is "7/1/55."
  26.  
  27. In that case there is an explicit-attribute component in the output.
  28. Compared with the argument relation schema, the component is
  29. "projected," i.e., attributes such as Name and Salary are missing.
  30.  
  31. Next, there is no valid-time component. The D-birth attribute is a
  32. user-defined time attribute.
  33.  
  34. So far we have "(Projected, None)."
  35.  
  36. Classifying the query with respect to v-t selection provides me with
  37. an opportunity to make a more general observation: Natural language
  38. language queries are notoriously imprecise compared with queries
  39. expressed in a temporal query language. Since the taxonomy comes from
  40. temporal query languages, the taxonomy is also "precise." This does
  41. make the classification of natural language queries a challenge. A
  42. good rule seems to be that "if it is hard to categorize a query then
  43. make it more precise."
  44.  
  45. Specifically, is there a hidden valid-time selection criterion in the
  46. query. If yes, what is that criterion?
  47.  
  48. In a query language we would typically be forced to specify when the
  49. birth date is supposed to be valid (often the default is the current
  50. time). Thus, I'll assume that the query is 
  51.  
  52.     Find the current date of birth of *ED*.
  53.  
  54. Since the birth date does not change, we know that the birth date
  55. valid at any other time is the same.
  56.  
  57. Now, there is a valid-time selection. Specifically, we select a date
  58. of birth if the associated valid time contains the event with the
  59. current time as value.
  60.  
  61. This gives (Containment, Event, Explicit).
  62.  
  63. Considering non-temporal selection, it seems clear that we have an
  64. equality predicate saying that the name attribute value should be the
  65. (current) name of *ED*. This yields (=, Constant). 
  66.  
  67. As an aside, I would probably phrase the query with an explicit
  68. reference to the name of *ED*. I would ask for the date of birth for
  69. the person who currently is named Edward.
  70.  
  71. The final result is
  72.  
  73. (Projected, None) / (Containment, Event, Explicit) / (=, Constant)
  74.  
  75.  
  76. I chose to address the more specific questions in your message only
  77. indirectly because I did not understand them fully!
  78.  
  79. Let me illustrate my problem.
  80.  
  81. > With reference to the last benchmark draft,
  82. > should the output of such queries be classified
  83. >     as:     (a) - (Projected, None) 
  84. >  or as:     (b) - (None, (*, "value") )   ?
  85.  
  86. The taxonomy has three parts, separated by "/"'s. No part has nested
  87. parenthesis. Thus, neither (a) nor (b) are syntactically correct.
  88. Should (a) be "(Projected, None)//"? What is (b)? I am sorry that I
  89. was not able to follow your thoughts...I am eager to learn more.
  90.  
  91. I think we will all identify problems with the database schema, the
  92. instance, and the taxonomy when we propose queries. I know that I have
  93. already. But I do not think it is realistic to change those parts and,
  94. at the same time, expect a finished benchmark before the TDB workshop.
  95. It will be impossible for contributors to keep up with the changes,
  96. and queries will have to be rewritten or recategorized every time a
  97. change is made. Can we even arrive at consensus fast enough to add
  98. changes? This is an experiment. The next benchmark can benefit from
  99. the lessons learned here.
  100.  
  101. Best regards,
  102. Christian
  103. csj@iesd.auc.dk